Thanks for the ping on Discord about this. I finally got a chance to take a look. 🙂

I got materials working (it seems), but all I did was put my old code from #91748 (review) back in and change some names to fit the new place where this implementation lives: 31@5eaf7cb.

Admittedly, my testing is still quite limited. Here's a simple scene that is looking good to me: https://gist.github.com/31/a3e597b32ab31b132ddbc488d8eb0324. The stress-test-ish scene with text also still seems to be working fine: https://gist.github.com/31/c3c4bace42d4ca550ae6badf0f2b7cf9. (Maybe even faster? Been a while.)

I like the change of where this logic lives (vs. #91748). However, I'm not following why the implementation details were changed. It seems significantly more complex and I can't spot what it's fixing. Do you have a test case that this helps with?

As far as I know the implementation details changed because Mesh became MeshGL in manifold. The rest of the changes were a result of this. I didn't like that fact that we are passing an increasingly growing material dictionary so that was removed, but I caused an error.

Thanks for fixing!

The developers working at manifold worked hard to remove exceptions and thrust, so we were able to vastly reduce the dependencies by 1/3. The changes here were due to api updates.

Exciting!

https://github.com/catprisbrey/Cats-Godot4-Modular-Souls-like-Template load this project crash!

After reverting this commit, the scene can be loaded normally.

@zhangjiangen11 Can you create a new issue? I suggest clearing .godot because I can't recreate the crash.

Here's a quick stress test of it. A few examples like this could feed into a very good blog post about it.

Can you post the script as an MIT-licensed GitHub project? The top portion of the sponge seems corrupted.

Here it is. csgmanifoldtest.zip

Set mengerdimension = 4 and it takes 2 minutes instead of 0.2 seconds.
Set holelength = 1.001 to ensure that the holes go all the way through

The holes gaps on the rotated combiners of boxes might be misaligned if 90degree rotation is implemented using the axis vectors (sin(1.5707963), cos(1.5707963)) instead of (0,1) (radians are evil).

I can't explain why one the triangles of the middle hexagram star on each edge is too large.

I modified the CSG snap values, and it seemed to work ok.

csgmanifoldtest 2.zip

Is snap implemented entirely differently in manifold?

I think these bits are different when you compare to the online version. No idea why. In fact the whole thing is a bit squiff in terms of the spread of the little holes. Might be something wrong in my code, though can't see what.

I associated godot engine snap with tolerance

There's no snapping in manifold itself. It almost looks like it's using 0.33 instead of a 1/3 or something. @fire even yours looks quite asymmetric and wrong to me.

I associated godot engine snap with tolerance

That might be dangerous... I'm not sure exactly how snap is used internally by Godot, but we use tolerance for mesh simplification, which can yield pretty unexpected results if the value gets too large.

We can deprecate snap and use the default manifold tolerance. How does that sound?

Yeah, that sounds good to me.

We can deprecate snap and use the default manifold tolerance. How does that sound?

I already saw an issue with the default snap/tolerance a while back, example in this issue: #93240

I'm not sure how to rectify the meanings, but from what I've seen, it probably matters to expose it somehow. Maybe you can get around it by scaling/unscaling, but that doesn't sound all that nice to deal with for prototyping in-editor.

(Edit: That all said, if the default tolerance for Manifold is (effectively) massively smaller than what anyone would be using, I suppose that's fine. 😄)

@31 - the issue you linked to is an example of the same problem: the mesh being broken by choosing too large a "snap" tolerance value. I still think @fire's approach will be the most reliable solution for that class of problems as well, particularly if snap is removed entirely.

the issue you linked to is an example of the same problem: the mesh being broken by choosing too large a "snap" tolerance value.

I understand that, but I don't have a sense for what the default Manifold tolerance behavior means. If I scaled the text 1/100, would the default behavior show a similar problem? 1/10000? Or is the default behavior close enough to floating point epsilon that it's difficult to even encounter that kind of problem?

I wasn't able to find any info in the Manifold docs that really told me what situation to expect here. 😕

Yes, the default is floating point epsilon.

Looks like this also fixed #94174.